home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000522_timbl@www3.cern.ch _Fri Jan 8 16:33:17 1993.msg < prev    next >
Internet Message Format  |  1994-01-24  |  4KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA00159; Fri, 8 Jan 93 16:33:17 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA21182; Fri, 8 Jan 1993 16:48:17 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA03037; Fri, 8 Jan 93 16:48:14 +0100
  8. Date: Fri, 8 Jan 93 16:48:14 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9301081548.AA03037@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: Dave_Raggett <dsr@hplb.hpl.hp.com>
  14. Subject: Re: HTTP2: Authentication
  15. Cc: www-talk@nxoc01.cern.ch
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18. Dave, I am splitting your message up into bits to keep the threads distinct.
  19.  
  20. >  From: Dave_Raggett <dsr@hplb.hpl.hp.com>
  21. >  Date: Fri, 8 Jan 93 13:48:18 GMT
  22.  
  23. >  Authentication
  24. >  --------------
  25. >  
  26.  
  27. >  I think that every HTTP2 request (not just GET) should include the "From"
  28. >  field, and that it is strongly desirable to include the user's full name,
  29. >  e.g.
  30. >  
  31.  
  32. >      From: dsr@hplb.hpl.hp.com (David Raggett)
  33. >  
  34.  
  35. >  The user's name must be easy to extract regardless of the particular variant
  36. >  of email addressing scheme.
  37. >  
  38.  
  39. >  For some services the server may need to check if the user is authorised for
  40. >  this service. In many cases the Internet (numeric) address and the  
  41. information
  42. >  in the "From:" field will suffice.
  43.  
  44.  
  45. I agree that low-level security is all that is needed in many cases.
  46. The IP address is quite good for licensing too.
  47.  
  48. >  Additional security will require a password. I think this should be a header
  49. >  in its own right. The "POST" command names a document that you wish to post  
  50. a
  51. >  response to. That document may not be owned by you so it doesn't seem right  
  52. to
  53. >  muddle up the authorisation for the POST command with that documents Udi.
  54. >  
  55.  
  56. >  so lets have a new header  "Password:  xyzzy"
  57.  
  58.  
  59. The passord certainly shouldn't be in the udi.
  60.  
  61. The hairy part is that we must be flexible about privacy shemes here.
  62. We may meet one lot committed to kerberos and another group comitted to  
  63. something else. So we should allow perhaps for a generic 'Authorization:' field
  64. and a number of rather extensive "refused" condidtions including the ones you  
  65. suggest and specifying the sort of authorization required.
  66.  
  67. rather than put passwords in the clear all the time (a reasonable low level
  68. scheme) the next setp is for the server to send back, along with the refusal, a
  69. random string to be encripted by the user using his key. This prevents anyone
  70. from breaking it unless they can put together the two messages, which is
  71. an extra hurdle.  The random string is related to the IP address the guy  
  72. originally used and will also time out, of course.
  73.  
  74. >  
  75.  
  76. >      a)  your Internet address is not permissible for this service
  77. >      b)  your user name is not permissible for this service
  78. >      c)  your password is incorrect
  79. >      d)  your password is ok, but the time check failed
  80.        e)  please send a kerberos ticket
  81.        f)  your kerboeros ticket is no good
  82.        g)  your IP address has just run out of license see body of message
  83.  
  84. We should look at Privacy Enhanced Mail -- the requiremenst must be similar.  
  85. All these schemes eventually rely on an established net of trusted servers  
  86. which doesn't exist right now, so we are putting in hooks for the future.
  87.   
  88.  
  89. >  Basic need for administrators identify and even to mail users.
  90.  
  91. yes. dunno about mail. Privacy issues... in general you can record who read and  
  92. what was read but not who read what.
  93.  
  94. >  Frequent need for authentication - not just on GET
  95.  
  96. yes.  Much more for checkin!
  97.  
  98. >  encrypt password + time of day to foil copying password
  99. >  
  100.  
  101. >  Needless to say the value for the Password header should be composed of
  102. >  printable 7 bit ascii characters, excluding white space and control chars.
  103.  
  104. yes.
  105.  
  106. Tim
  107.